Software vendors develop suites of applications for the purpose of providing a common user experience (UX) across a multiple applications and associated software functionality to a large set of users. However, corporations will have many different software requirements to handle human resources, financials, products, line-of-business (LOB) information, and so on.
It can be desirable to extend the common UX into the business realm by allowing LOB information and processes to be surfaced within the familiar UX of the office suite. This introduces other problems, however, particularly when handling data in offline scenarios, which oftentimes can occur when users travel, for example.
In a purely pessimistic offlining model, data about to be modified is locked and then unlocked after modification, which captures how typical on-line transaction processing (OLTP) systems behave. Alternatively, an optimistic offlining (and concurrency) model does not lock the data prior to the user making modifications.
In optimistic offlining in LOB systems, the LOB data and processes can be made available to the end-user in a local datastore while offline. When back online, the offline changes are seamlessly integrated with the LOB system, and any relevant changes in the LOB system are seamlessly integrated into the local datastore.
However, there are many limitations in the optimistic model. For example, there can be conflicting changes made by two different users while offline, which then need to be reconciled when both user systems are back online, the user could be dealing with out-of-date data while offline, the user's operations could be rejected (when back online) long after the operations are fired by the user (when previously offline), etc.
In contrast, there can be advantages of optimistic model. The model is resilient to connectivity issues, and changes coming in from multiple sources can be handled at the same time (referred to as “multiple-masters of data”). Additionally, the optimistic model works well when dealing with personal information (since conflicts in that case will only be with the user's own changes, which is very rare, e.g., user errors, out-of-date clients, data corruptions, etc., all of which are true exceptions), and the model works well when dealing with information that users explicitly collaborate upon (since information exchange is explicitly managed by a small known set of users, so even if conflicts occur, the users can work collaboratively to resolve the conflicts).
Most LOB systems do not employ optimistic offlining and concurrency models. LOB systems are masters (single masters) of the LOB data, and the actions that can be taken on the LOB systems are strictly controlled by business rules, not ad-hoc decisions of end-users. This is necessary since the accuracy and reliability of business data has direct influence on an enterprise's bottom line and can have legal/regulatory implications as well. Thus, the offline data synchronization when surfacing business data in office suite applications can be problematic.